I am using this action in our workflows to build. I am discovering that ECR does not like the attestation layers pushed when security scanning is enabled on a repository. It results in a Failed on the image UI state. Not a major issue, but sounds like this new feature to this action will let me turn these off with the newer docker buildx (0.10.0+) if my understanding is correct?

@farvour

I am using this action in our workflows to build. I am discovering that ECR does not like the attestation layers pushed when security scanning is enabled on a repository. It results in a Failed on the image UI state.

Is it because it cannot scan these indexes? Do you have more logs?

Not a major issue, but sounds like this new feature to this action will let me turn these off with the newer docker buildx (0.10.0+) if my understanding is correct?

That's correct, you might need to set provenance: false in this case.

@farvour

I am using this action in our workflows to build. I am discovering that ECR does not like the attestation layers pushed when security scanning is enabled on a repository. It results in a Failed on the image UI state.

Is it because it cannot scan these indexes? Do you have more logs?

Not a major issue, but sounds like this new feature to this action will let me turn these off with the newer docker buildx (0.10.0+) if my understanding is correct?

That's correct, you might need to set provenance: false in this case.

I believe it is because it doesn't understand what these SBOM layers are so it just leaves them as <untagged> with a failed state on the security scan. They show a size of 0.00 in the interface too. The part that sucks, is I cannot delete them either, because they belong to the parent Image List manifest and so ECR will just ignore delete operations. So I will forever have a junk failed layer in the history until the image index tag is removed.

I have a feeling ECR is just behind the 8-ball on this and needs to update their registry to properly support these provenance/SBOM layers. For the time being maybe I can just turn it off after this update is merged?

Here's an example of the CI job:

#22 exporting layers done
#22 exporting manifest sha256:94bcb18e169a8a6ff6ed325295b7c22e6364d2617c810a0172eebcd7550b5274 done
#22 exporting config sha256:73a683adec98435c4ae86501b59aed697408e6b910a824f117abd4e0d387ba5e done
#22 exporting attestation manifest sha256:4fc77dc4876c71812e965b8c3f63601dff30c373bee3bf4fdd4835db6a24a18d 0.0s done
#22 exporting manifest list sha256:8aecba85df1720416c73a10f2c8fe644f14bd6d534b736cbd49a8605dc139fa4 done
#22 pushing layers
#22 pushing layers 0.4s done

Here's what it looks like in ECR:

	<untagged>	
	January 11, 2023, 11:55:32 (UTC-08)	0.00	
	
sha256:4fc77dc4876c71812e965b8c3f63601dff30c373bee3bf4fdd4835db6a24a18d
	Failed (details)	-

Digest
sha256:4fc77dc4876c71812e965b8c3f63601dff30c373bee3bf4fdd4835db6a24a18d
General information
Artifact type
Repository
<REDACTED>
Pushed at
January 11, 2023, 11:55:32 (UTC-08)
Size (MB)
0.00
Scanning
Scan status
Failed
LayerError: Failed to extract layer for image scan.

@crazy-max how can I properly set provenance: false in this case?

      - name: Build
        uses: docker/build-push-action@master
        with:
          context: .
          push: true
          cache-from: type=registry,ref=ghcr.io/me/img:cache
          cache-to: type=registry,ref=ghcr.io/me/img:cache,mode=max
          tags: ghcr.io/me/img:latest
          provenance: false

it doesn't seem to work.

ERROR: invalid value false
Error: buildx failed with: ERROR: invalid value false

@nanake Thanks for your report, will fix that.